Remarks 

Status of application 

Claims 1-48 were examined and stand rejected in view of prior art. The claims 
have been amended to further clarify Applicant's invention. In view of the amendments 
made and the following remarks, reexamination and reconsideration are respectfully 
requested. 

The invention 

Applicant's invention provides a repository for banking/account information that 
consolidates information that may originate from a number of different sources, including 
Bank Administration Institute (BAI) files, SWIFT (Society for Worldwide Interbank 
Financial Telecommunication), back-end systems, and proprietary files. The solution 
stores information from these different sources in a central repository in a manner that 
improves the performance of the retrieval of banking/account information compared to 
prior art solutions which typically provide for retrieval of the information from a remote 
back-end (BE) system. Applicant's solution also provides a means for efficiently 
consolidating and storing historical account data. In addition, it provides common 
reporting schemes and paging mechanisms which provide users with easy access to the 
information in the central repository. The paging mechanisms enable the solution to 
present financial information to users in a manageable form that facilitates user 
navigation and use of the information. 

An important aspect of the Applicant's consolidation solution is that it avoids 
storing duplicate entries relating to the same transaction (e.g., one entry from a "live" 
system for the transaction and another from end-of-the-day data files). Additionally, 
Applicant's invention provides flexibility by enabling imported files (e.g., BAI files) to 
be "undone" when necessary. On occasion BAI files can contain errors that need to be 
corrected. However, correcting these errors can result in complications in providing the 
paging/navigation support for presenting the financial information to users. Applicant's 
invention therefore provides paging mechanisms enabling imported files to be "undone". 
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General 

A. Objections to Specification 

The Examiner has objected to the disclosure as containing embedded hyperlinks 
and indicated embedded hyperlinks were found at page 3 and 7-9 of Applicant's 
specification. Applicant has amended its specification to conform to the requirements of 
MPEP §608.01, thereby overcoming the objection. 

The Examiner also objected to the use of the abbreviations SWIFT as well as 
possibly other abbreviations. Applicant has corrected these informalities by spelling out 
the full names of the abbreviations SWIFT and several other abbreviations when they are 
first used in Applicant's specification as requested by the Examiner, thereby overcoming 
the Examiner's objection. 

Prior art rejections 

A. Section 102 rejection: Lewis 

Applicant's claims 1, 4, 18-21, 33-37, 43-46 and 48 stand rejected under 35 
U.S.C. 102(e) as being unpatentable over U.S. Patent No. 7,310,615 of Lewis (hereinafter 
"Lewis") The Examiner's rejection of Applicant's claim 1 is representative: 

Regarding claim 1 , Lewis discloses a system for consolidating financial 
transaction information from multiple sources for presentation to a user, the 
system comprising: a file importer for importing data files from a first source and 
processing each data file to create parsed information for each transaction present 
in the data file [Col. 4 line 66- Col. 5 line 12] and represent any additional 
information present in the data file in Extensible Markup Language (XML) 
format. [Col. 18 lines 17-20] 

Lewis discloses a data consolidator for receiving parsed information from the file 
importer, consolidating said parsed information with transaction information from 
a user accessible system to create consolidated transaction records, assigning a 
unique identifier [Col. 9 lines 6-9] to each consolidated transaction record for an 
account, and storing said consolidated transaction records. [See Claim 1] 
Lewis discloses a reporting module for receiving a request for financial 
transaction information for a particular account and presenting consolidated 
transaction records for the particular account to the user in response to the request, 
wherein the user may navigate through said consolidated transaction records 
based upon said unique identifier. [Col. 7 lines 21-24 and 47-49] 

Under Section 102, a claim is anticipated only if each and every element as set 
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forth in the claim is found, either expressly or inherently described, in the prior art 
reference. As described below in detail, the Lewis reference fails to teach each and every 
element set forth in Applicant's claims and therefore fails to establish anticipation of the 
claimed invention under Section 102. 

Although Lewis' solution has some features in common with Applicant's 
invention as they both describe consolidation of financial information from multiple 
sources, the nature of the consolidation that is performed by the two systems is 
fundamentally different . Lewis describes a consolidation system that stores all records 
derived from each of the sources, including both real-time and file-based sources. In 
doing so, Lewis duplicates considerable data as it stores records from live data during the 
business day as well as file-based transaction data which are typically received after the 
end of the business day . Applicant's invention, in contrast, recognizes that today's real- 
time transactions are tonight's file-based transactions and therefore the two sets of 
sources include large quantities of duplicate data. Applicant's solution operates to 
eliminate this duplicate data by replacing real-time transaction data with the officially 
posted transaction data when the official transaction data is available at the end of the 
day. 

The above-described differences may be illustrated by example. Consider, for 
instance, an example in which a bank customer performs a bill payment transaction. 
Lewis' solution would capture "live" data from a real time system about the bill payment 
transaction and store it in Lewis' data repository. At the end of the day, the bank issues a 
BAI-format file containing all of the day's transactions (typically with some additional 
information). Lewis's solution would also store this information in the repository. Thus, 
in Lewis' system the bill payment transaction would be stored in the repository twice: 
once from the real-time data source and once from the file-based data source. 

Applicant's solution, in contrast, does not simply store data received from both 
real-time data sources and file-based data sources regarding the same transaction. 
Instead, Applicant's solution consolidates real-time and end-of-day-file data intelligently 
so as to avoid duplicate data. This is described, for instance, in Applicant's specification 
as follows: 
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Assume, for example, that a bank receives a set of BAI files once per day and 
processes these files each day at midnight. During a particular day, a user (i.e., 
bank account holder) may request account data for a particular account 1234. In 
response, the reporting module 480 may obtain current data from the live system 
470 and use the data consolidator 450 to add the live data into the data 
consolidator's repository 460. The combined information from the live system 
and previously received data files relating to the particular account 1234 may then 
be displayed to the user in response to his or her request. The user may then issue 
a bill payment from this account at 2 pm in the afternoon of that same day. The 
data consolidator will update the account information to reflect the bill payment 
(based on information about the bill payment in the live system 470). That 
evening at midnight a new set of BAI files is received and processed, including a 
BAI file containing information relating to account 1234. The information in this 
BAI file may duplicate the information that came from the live system (e.g., 
because the BAI file includes a record of activity over the past 24 hours on 
account 1234). For example, the BAI file may include information reflecting the 
bill payment made from the account at 2 pm. When the system of the present 
invention processes data files (e.g., BAI files), the system will automatically 
purge any corresponding information in the repository which is marked as live 
from the user-accessible system. In this example, the bill payment record from 
the live system will be deleted as it is duplicated in the BAI file . 

(Applicant's specification, paragraph [0072], emphasis added) 

As illustrated above, the consolidation steps performed by Applicant's invention 
include removing duplicate entries. This reduces the quantity of the data that is 
maintained, provides increased consistency and improves performance. Applicant has 
amended its independent claims to bring these features to the forefront. For example, 
Applicant's amended claim 1 includes the following claim limitations: 

A system for consolidating financial transaction information from multiple 
sources for presentation to a user, the system comprising: 
a file importer for importing data files from a first source and processing each 
data file to create parsed information for each transaction present in the data file 
and represent any additional information present in the data file in Extensible 
Markup Language (XML) format; 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user- 
accessible system to create consolidated transaction records, assigning a unique 
identifier to each consolidated transaction record for an account, and storing said 
consolidated transaction records, wherein consolidating said parsed information 
includes removing transaction information derived from the user accessible 
system that is duplicated in said parsed information from the data files ; and 
a reporting module for receiving a request for financial transaction information 
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for a particular account and presenting consolidated transaction records for the 
particular account to the user in response to the request, wherein the user may 
navigate through said consolidated transaction records based upon said unique 
identifier. 

(Applicant's amended claim 1, emphasis added) 

Another difference between Applicant's solution and that of Lewis is that 
Applicant's system supports additional (i.e., custom) data fields in data files (e.g., BAI 
files) that are received. Moreover, it does so without having to modifying the underlying 
schema. One of the complications in processing BAI data files and storing them in a 
repository is that financial institutions frequently extend the BAI file format to provide 
additional (i.e., custom) fields or lines. Applicant's solution provides for handling and 
storing this additional information in the repository even though it may not be defined as 
a standard data element (i.e., in standard fields which arc expected). It docs so by 
creating an Extensible Markup Language (XML) representation of the additional 
information and storing this XML representation in the repository (see e.g., Applicant's 
specification, paragraphs [0066]-[0067]). When information from the BAI file is 
subsequently retrieved from the repository for presentation to a user, this additional 
information is reassembled for presentation to the user with the rest of the data from the 
BAI file (see e.g., Applicant's specification, paragraph [0066]). These features are 
included as limitations of Applicant's claims including, for instance, Claim 1 (quoted 
above) and dependent Claim 9. 

The Examiner references Lewis at col. 18, lines 17-20 for the corresponding 
teachings. However, Lewis is describing reformatting stored data in order to send it to 
other applications or user desktops (Lewis, col. 18, lines 8-10). In doing so, Lewis' 
solution reformats the data into a format readable by the target application or reformats 
the data into an XML message (Lewis, col. 18, lines 8-10). Thus, Lewis does not convert 
data into XML format for storage, but rather does the reverse in converting stored data 
into XML format for transmission. Additionally, Lewis makes no mention of processing 
data files containing additional (or extended) data fields. In fact, the focus of Lewis' 
system is on receiving and processing individual real-time messages or batch files of 
messages (Lewis, col. 9, lines 10-22 and lines 44-48). Lewis' solution includes a schema 
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or rules as to how incoming items of data are to be applied to the accounts, balances, and 
so forth represented in Lewis' system (Lewis, col. 9, lines 48-59). Lewis's system 
transforms incoming messages into a specified format (Lewis, col. 7, lines 24-27). 
Accordingly, the schema or rules of Lewis' system would need to be altered in order to 
accommodate additional data fields not included as part of the specified format or 
schema. Thus, Lewis' teachings are not comparable to Applicant's claim limitations of 
representing additional information present in a processed data file in XML format and 
storing this information in the repository. Additionally, Lewis makes no mention of 
retrieving the XML representation from the repository in response to a user request (e.g., 
as provided in Applicant's claim 9). 

Additionally, Applicant's methodology provides for ordering the transaction 
information and assigning a unique identifier (e.g., sequence number) to each transaction 
stored in the repository (see e.g., Applicant's specification, paragraph [0069]). This 
unique identifier facilitates paging the transaction information to the user in manageable 
groups or "chunks" of information, such as in groups of ten transactions organized based 
on sequence number (see e.g., Applicant's specification, paragraphs [0069]-[0070]). The 
user may, for example, then navigate through the transactions in sequence. The 
Examiner references Lewis at col. 7, lines 21-24 and 47-49 as including the 
corresponding teachings. However, Applicant's review of the above-referenced portion 
of Lewis, as well as the balance of the reference, finds no mention of assigning a 
sequence number or other unique identifier to each transaction record or for using such 
identifier to facilitate display of the information to the user. 

All told, Lewis does not include teachings of a consolidation system that 
consolidates real-time transaction data from a live system with file-based transaction data 
in a manner that avoids duplication of the data. Additionally, Lewis' solution does not 
gracefully handle additional data fields in input data files by converting such additional 
data to XML format and storing it in the repository as with Applicant's claimed 
invention. Moreover, Lewis makes no mention of assigning a unique identifier to each 
transaction and using this identifier to assist the user in navigating through transaction 
data. Therefore, as Lewis does not include all the limitations of Applicant's claims it is 
respectfully submitted that Applicant's claims distinguish over the prior art and overcome 
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any rejection under Section 102. 

B. First Section 103 Rejection: Lewis and Mehta 

Claims 2, 4 and 29 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above) in view of U.S. Published Application 2005/0096297 of Mehta et al 
(hereinafter "Mehta"). As to these claims, the Examiner relies on Lewis as substantially 
teaching the claimed invention, but acknowledges that Lewis fails to teach a file adapter 
for extracting data from a particular type of data file. The Examiner adds Mehta for these 
teachings. 

Under Section 103(a), a patent may not be obtained if the differences between the 
subject matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having 
ordinary skill in the art to which the subject matter pertains. To establish a prima facie 
case of obviousness under this section, the Examiner must establish: (1) that there is 
some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings, (2) that there is a reasonable expectation of success, and (3) 
that the prior art reference (or references when combined) must teach or suggest all the 
claim limitations. (See e.g., MPEP 2142). The Lewis and Mehta references, even when 
combined, fail to meet the requisite condition of teaching or suggesting all of Applicant's 
claim limitations. 

Applicant's claims are believed to be allowable for at least the reasons cited above 
(as to the Section 102 rejection) pertaining to the deficiencies of Lewis as to Applicant's 
invention. Mehta does not cure any of these deficiencies of Lewis. Mehta's solution is 
focused on processing of a message in an asynchronous architecture (Mehta, Abstract, 
paragraph [0009]). Although Mehta does describe adapters, the adapters described by 
Mehta are used to send or receive messages to particular business applications (Mehta, 
paragraph [0066]). Additionally, Mehta does not include teachings of a consolidation 
system that consolidates real-time transaction data from a live system with file-based 
transaction data as provided in Applicant's specification and claims. As Lewis and 
Mehta, even when combined, do not include all the limitations of Applicant's claims it is 
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respectfully submitted that Applicant's claims distinguish over the combined references 
and overcome any rejection under Section 103. 

C. Second Section 103 Rejection: Lewis and Campbell 

Claims 3, 23 and 38 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above) in view of U.S. Patent 6,856,970 to Campbell et al (hereinafter 
"Campbell"). Applicant's claims are believed to be allowable for at least the reasons 
discussed in detail above pertaining to the deficiencies of Lewis as to Applicant's 
invention. Although Campbell describes a BAI format mapper which accounts for 
different interpretations of BAI used at different banks, it does not include any teaching 
of a system that consolidates real-time transaction data with file-based transaction data 
comparable to Applicant's claimed invention. Accordingly, Campbell does not cure any 
of the above-described deficiencies of Lewis as to Applicant's invention. As the 
combined references do not include all the limitations of Applicant's claims it is 
respectfully submitted that Applicant's claims distinguish over the Lewis and Campbell 
references and overcome any rejection under Section 103. 

D. Third Section 103 Rejection: Lewis and Anaya 

Claims 10, 25 and 40 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above) in view of U.S. Published Application 2005/0096297 of Anaya et al 
(hereinafter "Anaya"). As to these claims, the Examiner acknowledges that Lewis does 
not disclose that the unique identifier assigned to a transaction record comprises a 
sequence number. 

Applicant's claims are believed to be allowable for at least the reasons described 
above pertaining to the deficiencies of Lewis. Additionally, Applicant's solution 
provides for assigning a unique identifier (e.g., sequence number) to each transaction 
stored in the repository to facilitate paging the transaction information to the user in 
manageable groups or "chunks" of information as previously described. Lewis does not 
include comparable teachings of assigning a sequence number to each transaction record 
and using the sequence number to facilitate display of the information to the user. 
Although Anaya describes a sequence number, it does so in a very different context. In 
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Anaya's system a sequence number is associated with incoming or outgoing messages so 
as to provide an ordering for the messages (e.g., to ensure all messages are received in 
sequence). Moreover, Anaya makes no mention of using the sequence number to 
facilitate display of transaction data to a user and/or to allow a user to navigate through 
such data as provided in Applicant's specification and claims. Therefore, as Lewis and 
Anaya, even when combined, do not include all the limitations of Applicant's claims it is 
respectfully submitted that Applicant's claims distinguish over these references and 
overcome any rejection under Section 103. 

E. Fourth Section 103 Rejection: Lewis, Anaya and Riehl 
Claim 1 1 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above) in view of Anaya (above), further in view of U.S. Published Application 
2006/0080255 of Riehl et al (hereinafter "Riehl"). Here, the Examiner acknowledges that 
neither Riehl nor Anaya include teachings of assigning a sequence number per account 
and type of transaction and adds Riehl for these teachings. 

Again, Applicant's claims are believed to be allowable for the reasons described 
above pertaining to the deficiencies of Lewis and Anaya, none of which are cured by 
Riehl. Additionally, Riehl simply describes that a transaction entry contains pertinent 
details regarding the transaction including "a transaction sequence number; the 
transaction type; account number; and the dollar amount" (Riehl, paragraph [0030]). It 
does not include the specific teachings of Applicant's claim 1 1 of a data consolidator 
which assigns a sequence number "per account and per type of transaction". By 
assigning sequence numbers per account and type of transaction in this fashion, 
Applicant's invention can efficiently extract pages of information based on a range of 
sequence numbers for any particular account and type of transaction (see e.g., 
Applicant's specification, paragraph [0069]). Respectfully, the teachings of Riehl are not 
comparable to these features of Applicant's invention. Thus, as the combined references 
do not include all the limitations of Applicant's claim 11 it is respectfully submitted that 
Applicant's claim 1 1 (and other claims) distinguish over the combined references and 
overcome any rejection under Section 103. 
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F. Fifth Section 103 Rejection: Lewis, Anaya, Riehl and Xu 

Claim 12 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above) in view of Anaya (above), in view of Riehl (above) and further in view of 
U.S. Published Application 2002/0004773 of Xu et al (hereinafter "Xu"). Claim 12 is 
dependent upon Applicant's independent claim 1 and intervening claims 10 and 1 1 and 
is, therefore, believed to be allowable for the reasons discussed in detail as to the 
deficiencies of Lewis, Anaya and Riehl as to Applicant's claimed invention. Xu does not 
cure these deficiencies as Xu includes no teaching of a system that consolidates real-time 
transaction data with file-based transaction data comparable to Applicant's claimed 
invention. Additionally, Xu simply describes a assigning a monotonically increasing 
sequence number for each certificate revocation list (CRL) issued by a given certificate 
authority (CA). Applicant respectfully believes these teachings are not analogous to a 
data consolidator which assigns consecutive sequence numbers to transaction records of a 
given type for a particular account. Therefore as the combined references do not include 
all the limitations of Applicant's claims, it is respectfully submitted that the claims 
overcome any rejection under Section 103. 

G. Sixth Section 103 Rejection: Lewis, Anaya, Riehl and Hughes 
Claims 13-14, 26 and 41 stand rejected under 35 U.S.C. 103(a) as being 

unpatentable over Lewis (above) in view of Anaya (above), in view of Riehl (above) and 
further in view of U.S. Patent 5,764,655 to Hughes et al (hereinafter "Hughes"). Again, 
these claims are believed to be allowable for the reasons discussed in detail as to the 
deficiencies of Lewis, Anaya and Riehl as to Applicant's claimed invention as well as for 
the following additional reasons. 

Hughes describes a system for remote purchase and bill payment transactions. 
Hughes system provides for a "retrieval reference number" which is generated to aid in 
tracking a transaction within the processing system. Hughes' retrieval reference number 
is based on the least significant digit of the year, the gregorian date and a sequence 
number that is reset at the beginning of each day and incremented for each transaction. 
Applicant's claimed invention, in contrast provides for assigning sequence numbers to 
transaction records of a given type for a particular account. Additionally, Applicant's 
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solution provides for two alternative paging schemes and related sequence numbers 
which can be implemented by a user or organization (e.g., a bank) depending on its 
environment and requirements which are referred to as "consecutive" and "date -based" 
paging. The format of the sequence numbers that are assigned are based on which type 
of paging scheme the customer has selected (see e.g., Applicant's specification, 
paragraph [0069]). The "consecutive" scheme provides for assigning consecutive 
sequence numbers, while the "date-based" scheme provides for sequence numbers that 
include calendar date information (see e.g., Applicant's specification, paragraph [0069]). 
Hughes system does not provide comparable features or flexibility. Instead, Hughes 
creates a reference number based on a combination of date (i.e., year and Gregorian date) 
and a sequence number which is reset each day. Respectfully, these teachings are not 
comparable to the limitations of Applicant's claims 13-14, 26 and 41 . Thus, as the 
combined references do not include all the teachings of Applicant's claims, Applicant 
respectfully submits that its claimed invention distinguishes over these references. 

H. Seventh Section 103 Rejection: Lewis and Pelly 

Claim 15 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above) in view of U.S. Published Application 2002/0044684 of Pelly (hereinafter 
"Pelly"). Claim 15 is believed to be allowable for the reasons discussed in detail as to the 
deficiencies of Lewis as to Applicant's claimed invention. Additionally, the referenced 
teachings of Pelly describe data compression encoding and decoding, which Applicant 
does not believe are analogous to Applicant's solution which will undo transaction 
records derived from a particular file in response to a user request to undo the file. As the 
combined references do not include all the teachings of Applicant's claims, Applicant 
respectfully submits that its claimed invention overcomes the Section 103 rejection. 

I. Eighth Section 103 Rejection: Lewis and Smith 

Claim 16 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above) in view of U.S. Published Application 2002/0042975 of Smith (hereinafter 
"Smith"). Claim 16 is believed to be allowable for the reasons discussed in detail as to 
the deficiencies of Lewis as to Applicant's claimed invention. Claim 16 is dependent on 
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claims 1 and 15 and is, therefore, believed to be allowable for the reasons set forth above 
as to the deficiencies of Lewis as to these independent and intervening claims. Smith 
does cure any of these deficiencies. Additionally while Smith describes identifying 
dependent files, Smith makes no mention of undoing or reprocessing any files or 
dependent files as provided in Applicant's specification and claims. For the reasons set 
forth above, Applicant respectfully submits that its claimed invention distinguishes over 
the combined references and overcomes the Section 103 rejection. 

J. Ninth Section 103 Rejection: Lewis, Smith and Pelly 
Claim 17 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Lewis (above) in view of Smith (above) and Pelly (above). Claim 17 is dependent on 
claims 1,15 and 16 and is, therefore, believed to be allowable for the reasons set forth 
above as to the deficiencies of Lewis, Smith and Pelly as to these independent and 
intervening claims. In particular, none of the prior art references describes undoing 
transaction records derived from a particular file in response to a user request, nor do they 
describe identifying and reprocessing records which are dependent on the file being 
undone as provided in Applicant's specification and claims. Accordingly, Applicant 
respectfully submits that its claimed invention distinguishes over the combined references 
and overcomes the Section 103 rejection. 

K. Tenth Section 103 Rejection: Lewis and Schulze 

Claims 27 and 42 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above) in view of U.S. Published Application 2006/0041493 of Schulze et al 
(hereinafter "Schulze"). Applicant's claims are believed to be allowable for at least the 
reasons described above pertaining to the deficiencies of Lewis. Schulze does not cure 
these deficiencies as the referenced teachings of Schulze simply describe making a back- 
up file of downloaded identification data and routing codes and storing it in an off-site 
storage system. Therefore, Applicant respectfully submits that its claimed invention 
distinguishes over the combined references and overcomes the Section 103 rejection. 
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L. Eleventh Section 103 Rejection: Lewis and Osborne 

Claims 32 and 47 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Lewis (above) in view of U.S. Published Application 2003/00120619 of Osborne et 
al (hereinafter "Osborne"). Applicant's claims are believed to be allowable for at least the 
reasons described above pertaining to the deficiencies of Lewis. Osborne describes a 
solution for remote monitoring and diagnosing of industrial equipment and, therefore, 
does not cure any of these deficiencies. Therefore, Applicant respectfully submits that its 
claimed invention distinguishes over the combined references and overcomes the Section 
103 rejection. 

Any dependent claims not explicitly discussed are believed to be allowable by 
virtue of dependency from Applicant's independent claims, as discussed in detail above. 

Conclusion 

In view of the foregoing remarks and the amendment to the claims, it is believed 
that all claims are now in condition for allowance. Hence, it is respectfully requested that 
the application be passed to issue at an early date. 

If for any reason the Examiner feels that a telephone conference would in any way 
expedite prosecution of the subject application, the Examiner is invited to telephone the 
undersigned at 925 465 0361. 

Respectfully submitted, 

Date: May 16, 2008 /G. Mack Riddle/ 

G. Mack Riddle; Reg. No. 55,572 
Attorney of Record 

925 465 0361 

925 465 8143 FAX 
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